Contemporary computer systems offer users assistive technology, typically for providing visually-impaired users with better accessibility to computers. For example, screen readers can be used to output text to speech and Braille, while screen magnification programs can be used to make displayed screen content more viewable.
Previous assistive programs worked by inserting a driver in the video path above the main display driver (essentially in a serial display driver chain) to intercept graphics primitives, processing the primitives to build an off screen model, and then outputting the off screen model in some way. An improvement in assistive technology includes mirror drivers, which unlike chained drivers are not inserted into the video path of the main display driver. Instead, a mirror driver essentially receives graphics primitives as a peer to the main display driver.
A recent accessibility technology that provides an alternative to (or a complement to) driver-based magnifiers is described in U.S. patent application Ser. No. 11/180,859, filed Jul. 12, 2005, assigned to the assignee of the present invention and hereby incorporated by reference. This technology is (among its aspects) generally directed towards a magnification engine and API (application programming interface) that magnifier applications can leverage, and that renders a magnifier in software and/or hardware.
Among the requirements of assistive technology programs is that they correctly reflect what is on the display screen. This causes problems with device independent bitmaps (DIBs), because for such bitmaps the display driver is not called with the instructions that modify the bitmap. For example, application calls to GDI (the graphics device interface of Microsoft® Windows®) may result in a device independent bitmap being drawn to a separate surface. GDI itself also may not forward all such calls to drivers at the driver level. In general, the driver can only see the bits, but not the calls that drew the bits.
As a result, an accessibility display driver, whether chained or mirrored, is never aware of drawing calls made to such bitmaps via the usual rendering path, and only sees the resultant bits. However there is a lot of information in these calls that an accessibility driver needs to see. For example, a text-to-speech or text-to-Braille converter wants to see the actual text that is to be drawn, rather than the bits that resulted from the text being drawn.
Approaches to solving this problem include patching operating system components (e.g., Win32k.sys) in memory, or calling undocumented kernel interface entry points, in order to populate off-screen models with information about drawing calls to off-screen device independent bitmaps (DIBs). These approaches are particularly volatile with respect to system stability and integrity, and as such are not desirable.
Another way to capture calls to device independent bitmaps (DIBs) in a serial display driver chain model is to modify surface data structures, in order to associate a surface with the display driver that wants to capture the calls. As a result of the association, any drawing to this surface (DIB) is sent to the chained display driver that performed the modification. When this occurs, the chained display driver is able to disassociate the real display driver from the surfaces before forwarding the call, e.g., by resetting flags in the surface data structure, and calling support functions if the source and destination bitmaps are both device independent bitmaps. Note that when this condition is not fulfilled, the call is forwarded to the real display driver.
However, with a mirror driver, this same technique cannot be used without potentially crashing other mirror drivers, because once the surface association is made, all mirror drivers will get calls in parallel, including for bitmaps for which they have not allocated a device dependent bitmap. As a result, specific methods involving surface association calls are incompatible when multiple accessibility mirror drivers are on the system.